When downloading software to an Electronic Control Unit (ECU) of a vehicle there is a risk that something goes wrong. Should something go wrong there is further a risk that the total amount of ECU software may not be complete or potentially different parts of the software not compatible with each other. This may e.g. be the result of an aborted programming event, leaving the ECU only partially programmed.
Should the software of the ECU not be complete or components thereof not compatible, this may have as a result that the ECU is unable to communicate properly to initiate a new programming event.
In some of today's software download concepts there is only a simple detection whether an application is valid or not. This detection does not include the total amount of software of the ECU, neither does this detection include any check that different parts of the software stored in the ECU are compatible with each other.
An obvious safeguard would be to have a bootloader of the ECU perform a check that the software components of the ECU are complete and compatible with each other at every start-up.
However, as the bootloader of the ECU normally will be fix and burnt into a memory circuit of the ECU, it is normally not possible to change the bootloader without replacing the hardware of the ECU. Thus the number of software components to check for completeness and compatibility will be fix unless the ECU is replaced. However, it is not feasible to replace the ECU every time there is a need to include an additional software component.
Thus, there is a need for introducing a more controlled start-up of an application for verifying if the software components of the ECU are complete and compatible with each other.